The present invention is generally related to an Internet addressing system and, more particularly, to a system and method that maintains linkage between Internet addresses and the ultimate web page locations of those addresses, even where links in the Internet addresses have been broken, altered or modified.
Much of the flexibility and interconnectedness provided by the Internet and the World Wide Web is due to the extensive links that exist between webpages. Each link is the address of another webpage (or image, or sound file, or cgi-script, or other object, all of which will be referred to herein as webpages), which may reside on a different website (i.e. a different host domain) than the page containing the link, or may be contained within the same website.
The Web contains hundreds of millions of webpages, and billions of links. But as any web surfer knows, many of those links are “broken”, pointing to nowhere because the page they once pointed to no longer exists at that address.
Webpages are typically accessed through use of a web browser, though other software programs, such as Internet search utilities, may do so as well, as may a variety of built-in functions of other software products. (As used herein, the term “web browser” is meant to encompass all these means of accessing URLs.) Links may be either “absolute” or “relative”. An absolute link consists of a webpage address in the form of a Uniform Resource Locator (URL), which has the format:    http://host.domain/path/filenameWhere:    “host” is, typically, www    “domain” is (for IBM's website) ibm.com    “path” is the fully qualified path-address of the file denoted by “filename”, comprising the target webpage, reflecting the file's location within the hierarchical directory structure of the computer on which the file resides. For example, if on the IBM website there is a sub-directory of the root directory with the name “products”, and if the “products” directory contains a further sub-directory called “hardware”, and if the “hardware” directory contains a further sub-directory called “servers”, and if the “servers” directory contains a further sub-directory called “aix”, and if the “aix” directory contained a file called “howtobuy.htm”, the path-address of “howtobuy.htm” would be:    /products/hardware/servers/aix/howtobuy.htmand the URL comprising an absolute link would be:    http://www.ibm.com/products/hardware/servers/aix/howtobuy.h tm
By default, a URL points to the beginning of a webpage, as does the above example. However, if the creator of the webpage has named any internal sections of the webpage, it then is possible to link to those sections directly. For example, the section dealing with payment terms within the “howtobuy.htm” webpage could be given the name “PT” by using the following HTML tag, positioned at the beginning of the applicable text:    <A NAME=“PT”>The following URL could then be used to link to the specific text dealing with payment terms:    http://www.ibm.com/products/hardware/servers/aix/howtobuy.h tm#PT
Often, the filename itself may be omitted from a URL. Many web servers adopt a convention that if a filename is absent, a specific filename is assumed, often “index.htm” or “index.html”. For example, if the “howtobuy.htm” file were renamed “index.htm”, the following URL would link to it, even without supplying the filename explicitly:    http://www.ibm.com/products/hardware/servers/aix
Relative links consist of the relative path from the current webpage to the linked-to webpage. For example, if there was a webpage on IBM's website named “hwlist.htm” in the /products/hardware/ directory, it would have a URL of http://www.ibm.com/products/hardware/hwlist.htm. The hwlist.htm webpage might contain a number of links to other pages, including a link to the howtobuy.htm file described above. Instead of using the absolute link described above, a relative link could be used, which would be:    /servers/aix/howtobuy.htm
Web browsers form absolute links from relative links by combining the relative link with the path of the current webpage. They do this by concatenating the relative link together with the full path of the current webpage to form the full URL of the linked-to page, which is then used to access the linked-to page. In the example given above, when the relative link (/servers/aix/howtobuy.htm) is concatenated with the path of the hwlist.htm webpage itself (http://www.ibm.com/products/hardware) the result (http://www.ibm.com/products/hardware/servers/aix/howtobuy. htm) is the absolute URL of the linked-to page.
An advantage of using relative links when constructing webpages is that that if a webpage and all its direct or indirect sub-pages are severed from their existing location and moved to another location in the webpage tree, the relative links, which give the path information of the desired target webpage relative to the current location, continue to operate in the desired manner without modification.
A webpage may link to another, target, webpage by embedding within its HTML the address, in the form of the URL, of the target webpage. A particular URL uniquely identifies a particular webpage. For example, www.ibm.com is the URL of IBM's home page. Pages within IBM's website have URL-addresses that reflect their hierarchical location on the computer hosting the website. The page devoted to servers has a URL of www.ibm.com/servers, the page describing a particular server, the AIX computer, has a URL of www.ibm.com/servers/aix, and the page describing how to buy an AIX computer has the URL of www.ibm.com/servers/aix/howtobuy.htm. Someone wishing to, let's say, create a directory-webpage comprising a list of available computer equipment could point into the IBM website, perhaps linking to the AIX product-description at www.ibm.com/servers/aix, and the purchasing information at www.ibm.com/servers/aix/howtobuy.htm. These URLs may be manually transcribed into the HTML of the directory webpage, or they may be quasi-automatically captured while viewing the applicable page with a browser (such as Microsoft Internet Explorer or Netscape Navigator) by saving a bookmark or copying the current-URL line, then pasting this data into the HTML.
But, if IBM subsequently changes the structure of its website, any URLs previously gathered may no longer be valid. For example, if the page on servers became subordinate to a page devoted to “hardware” the server-page might have a new URL of www.ibm.com/hardware/servers and the AIX-page would have a new URL of www.ibm.com/hardware/servers/aix. Or, the IBM website might be changed from a static structure, with each page predefined, to a dynamic structure where certain pages are generated on-the-fly by a program operating on the server. For example, the URL www.ibm.com/aw-cgi/ibmISAPI.dll?ViewItem&item=259 might invoke a cgi-script named ibmISAPI, which would expect to receive an item-code corresponding to the product in question, in this example 259, corresponding to AIX. The cgi-script would use the item-code to access a database, retrieve information about the product, and build the webpage to be displayed. Or, IBM could consolidate all the information from a variety of servers, including AIX, on a single page with the URL www.ibm.com/hardware/allservers, in which case the AIX information would be embedded somewhere within this composite page.
If the prior AIX-related URLs (www.ibm.com/servers and www.ibm.com/servers/aix) had been used in any other pages as links, they would no longer work, even though the information—the content—of the pages they originally linked to still exists, though not at the same location as previously. (Note that this is fundamentally unlike certain other situations causing broken links in which the content is simply gone, such as a deleted website, an out-dated news article, or a discontinued product.) The Webmaster of the directory-webpage would not be alerted to the fact that IBM had changed the structure of their website, causing some of the links in the directory-webpage to become broken, and could only determine this fact by constant checking. In fact, there are products like Xenu's Link Sleuth or services like LinkAlarm that are specifically directed at finding and reporting on broken links by constantly or periodically monitoring the website containing them. Some websites even ask visitors to fill out a form, reporting on any broken links they may have encountered.
But however a broken link may be discovered, it usually must be fixed manually. To fix the links broken by IBM's hypothetical reorganization of its website, the webmaster of the directory-website would typically have to visit the IBM website, find the new locations of the pages that the links used to point to, copy their present URLs, and recreate the links.
A similar situation exists for those individuals who create bookmarks or favorites, which are essentially identical to links, and can be broken in the same way.
And broken links can also occur within the restructured website itself, not just externally. It's very common for the pages of a website to cross-link to one another, to allow the user to navigate to anywhere, from anywhere, and some of these links can break whenever any restructuring takes place. And relative links, which are extensively used to link within a website, though insensitive to changes to the path that occur “above” the page containing the relative link, are readily broken by any changes in the path “below” the containing page.
The author or Webmaster of the IBM website could attempt to avoid the problem of broken links by providing “redirect” instructions to the web server serving the IBM website domain. These “redirect” instructions specify both the old URL (the one that no longer exists) and the new URL that accesses to the old URL should be directed to instead. For example, accesses to the first version of the AIX page www.ibm.com/servers/aix, in this example now defunct, could be redirected to the second version at www.ibm.com/hardware/servers/aix. The web server typically effects the redirection by returning the new URL to the browser, along with an appropriate indicator; the browser then simply reprocesses the URL in the usual manner, thereby accessing the new webpage. As an alternative, a web server may itself access the new webpage and return it to the browser in response to the original request (the “old” URL), however in this instance the web server must still supply back to the browser the new URL. (Note that this is required because web browsers, as described previously, process relative links by concatenating them with the absolute URL of the page containing the relative link. Therefore, if redirection occurs, in order to be able to process relative links if any are encountered, the web browser must be informed by the web server as to the actual URL of the page that the original request was redirected to, and which was returned to the web browser for display. In the present example, though the browser may have requested www.ibm.com/servers/aix, the page actually returned to the browser has the URL www.ibm.com/hardware/servers/aix, and the browser would receive this updated URL from the server.) But, if the IBM website is restructured again, the redirection instruction might have to be changed so that accesses to the first AIX page, www.ibm.com/servers/aix, are now redirected to the third version at www.ibm.com/aw-cgi/ibmISAPI.dll?ViewItem&item=259. Moreover, since there will also continue to be accesses to the second version, another redirection instruction would have to be created so that accesses to the second version, www.ibm.com/hardware/servers/aix, are also redirected to the third version, www.ibm.com/aw-cgi/ibmISAPI.dll?ViewItem&item=259. This procedure illustrates the deficiencies of the redirection technique, which requires that each earlier version of a webpage be redirected to the current version of that webpage, and that each of these redirection instructions remain in place indefinitely, all of which is cumbersome, burdensome, and error-prone.
In addition to being used as links, URL addresses are often simply typed into the browser by the computer user. But URLs are often difficult if not impossible to remember (in one of the prior examples, the user would have to remember that www.ibm.com/aw-cgi/ibmISAPI.dll?ViewItem&item=259 is the URL for the AIX page), laborious to type, and subject to being broken or outdated in the same way as URLs used as links.
In response to these deficiencies, several firms, including Netword Inc. and RealNames Corporation, have devised systems in which users can type easy-to-remember keywords into their browsers in place of URLs. (Netword Inc. is the holder of U.S. Pat. No. 5,764,906: “Universal electronic resource denotation, request and delivery system”.) For example, if “AIX” had been established as such a keyword, a user could simply type “AIX” into his browser and be taken to the current appropriate webpage, such as www.ibm.com/aw-gi/ibmISAPI.dll?ViewItem&item=259. This is accomplished through use of a central database maintained by the proprietors (such as Netword or RealNames) of the keyword system that correlates each keyword with the applicable URL. When a user types something that looks like a keyword into a browser, the browser uses it to access the keyword database. If it's a defined keyword, the database returns the corresponding URL to the browser, which then processes that URL as if the user had typed it in. The responsibility typically rests with the webmasters of each participating website to use the facilities of the keyword system to assign the keywords, associate the appropriate URL, and update the database whenever restructuring of their website causes changes to any of the URLs associated with keywords.
A problem with keyword systems is that there is no single central keyword database: both Netword and RealNames maintain their own databases. Particular keywords might be defined in one system but not the other, or might be defined in both, but conflict with one-another. For example, the IBM webmaster might register “AIX” as a Netword keyword, and associate it with a page on the IBM website, but some other webmaster, perhaps associated with a company selling AIX-related software, or the Allied Insurance Exchange, may have previously registered “AIX” with RealNames. In this example, for a user who types in a keyword of “AIX”, the webpage that the user is eventually taken to will depend on which database the keyword is looked up in. Keywords, being short, provide a limited name-space that will inevitably lead to conflicts and collisions. For example, consider that “Explorer” is the name of a browser (from Microsoft), a sport-utility vehicle (from Ford) and the name of a Boy Scout program. Each of these organizations might wish to use “Explorer” as a keyword tied to a URL within their website. Further contributing to erratic results is the fact that different browsers give precedence to different keyword systems. For example, Microsoft Internet Explorer looks keywords up in the RealNames database, but does not consult Netword. Netscape Navigator does not use RealNames (perhaps because RealNames is partially owned by Microsoft), but can readily be customized to consult Netword. And AOL has its own system of keywords, unrelated to RealNames or Netword, that only functions for users of the AOL online service. Moreover, creating keywords can be expensive. RealNames charges an annual fee of $100 per keyword (which is greater than the annual fee to keep a domain name active) and many organizations might wish to maintain dozens or even hundreds of keywords.
Another deficiency associated with the use of keywords is that since the browser immediately translates each keyword to its associated URL and then uses that URL for further processing, if the person using the browser bookmarks (or copies, either manually or programmatically) that URL, or the URL of any subsequent webpage that the initial page might directly or indirectly link to, whether absolutely or relatively, that bookmarked or copied URL is fully vulnerable to being broken in the future, just as if a keyword had never been initially employed.
In summary, URLs are hard to remember and, when used as links, are fragile and easily broken. The process of discovering and repairing broken links is unsystematic and extremely laborious. Keyword aliases for URLs are expensive, unreliable and inconsistent, discouraging website owners from creating and publicizing them. The present invention describes several methods, which would greatly minimize the incidence of broken links, while also providing easily remembered or inferred URLs that would behave in a reliable, predictable fashion.